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(57) Abstract 




A system for object oriented mes- 
sage filtering for selectively transferring 
a message between a client task and one 
or more server tasks for preprocessing, 
processing, and postprocessing comprises 
an object database having a filter object 
memory, an object management unit, a 
message transaction unit, and a locking 
unit The object management unit cre- 
ates a port object and one or more asso- 
ciated target message objects, llie object 
management unit selectively creates one 
or more filter objects associated with a 
target message object, and selectively as- 
sociates a preprocessor message object, a 
postprocessor message object, or both a 
preprocessor message object and a post 
processor message object with each filter 
object Hie message transaction unit se- 
lectively routes a message sent by a client 
task and directed to a target message ob- 
ject to one or more associated preproces- 
sor message objects prior to deliveiing 

the message to the t^et message object After delivery to the target message object, the message transaction unit selectively routes 
the message to one or more associated postprocessor message objects. Server tasks receive messages from port objects associated with 
preprocessor message objects, target message objects, and postprocessor message objects, facilitating preprocessing, processing, aixi post- 
processing operations. An object oriented message filtering method comprises the steps of: creating a port object; creating a target message 
object associated with the port object; creating a filter ob^ associated with &e target message object; creating a preprocessor message 
object associated with the filter object; generating a unique message ID in response to a message transaction initiated by a send message 
request; creating a send message control block; and selectively routing the send message control block to the preprocessor message object 
prior to delivering the send message control block to the target message object 
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SYSTEM AND METHOD FOR OBTE CT ORTENrTRD MESSAGF Fn.TFT^TMn 

CROSS-REFERENCE TO RELATED APPLTCATTOM^ 
The present invention relates to U.S. Patent Application Serial No. 
08/220,043, entitled "Object Oriented Message Passing System and Method/' filed 
on March 30, 1994, which is incorporated herein by reference. 

B ACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally to systems and methods for intra- 
computer commimication, and more particularly, to systems and methods for 
message-based client-server commimication. Still more particularly, the present 
invention is a system and method for object oriented message filtering. 

2. Description of the Back ground Art 

In intra-computer communications, a client task requires a service 
provided by a server task. For example, a client task may require window creation 
or file deletion services. The particular service diat the client task requires is 
performed by an appropriate server task, such as a window manager or a file 
system. A message is the unit of commimication interchange between a client 
and a server. Thus, in order to inform a server that a particular service is 
required, the client task sends or issues an appropriate message. Upon receiving 
an issued message, the server task performs the required actions. As described in 
U.S. Patent Application Serial No. 08/220,043, message passing systems and 
methods determine the maimer in which a message that has been issued by a 
client task is delivered to a server task. 

In the prior art, each time a client task requires a service, the client task 
must send a message. Often, the performance of a particular service requires the 
performance of one or more additional, related services. For example, the 
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performance of a service that results in the writing of data to a disk file may also 
require a first related service for data encryption and a second related service for 
data compression. Thus, a total of three messages must be sent by a client task in 
this example to perform the desired encryption, compression, and writing of the 
5 data to the disk file. Each message sent increases the memory overhead required 
to deliver the message to an appropriate server task for processing. Moreover, 
each message must be sent and serviced in the proper order, and client tasks must 
keep track of all server tasks to which messages must be sent when the related 
services are required. Each of the aforementioned drawbacks adversely increases 
10 client task and server task complexity. 

What is needed is a means for message transfer that minimizes memory 
overhead requirements and that isolates client tasks and server tasks from 
imnecessary complexity when multiple server tasks are to perform operations 
upon a message. 

15 

SUMMARY OF THF INVENFTION 
The present invention is a system and method for object oriented message 
filtering. In the present invention, a message sent by a client task is selectively 
and automatically transferred to one or more server tasks for preprocessing, 

20 processing, and postprocessing. The system of the present invention comprises a 
processing unit and a memory wherein an object oriented message filtering unit 
resides. The object oriented message filtering tmit creates and maintains one or 
more port objects and one or more target message objects. For each target message 
object, the object oriented message filtering unit selectively creates and maintains 

25 one or more associated filter objects. The set of filter objects that are associated 
vrfth a particular target message object are referred to as a filter object chain. For 
each filter object, the object oriented message filtering unit selectively creates and 
maintains an associated preprocessor message object, an associated postprocessor 
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message object, or both an associated preprocessor message object and an 
associated postprocessor message object. Each target message object, preprocessor 
message object, and postprocessor message object is associated with a port object. 

A client task sends a message directed to a target message object by issuing a 
send message request. The message referenced in the send message request itself 
indicates a required service. In response to a send message request, the object 
oriented message filtering unit creates a send message control block (MCB) that 
includes a imique message ID and a reference to the message. The object oriented 
message filtering unit delivers a message to a particular message object by storing a 
reference to the send MCB in the port object associated with the message object. 
Prior to delivering the send MCB to the target message object, the object oriented 
message filtering unit automatically and selectively routes the send MCB to 
preprocessor message objects associated with the target message object via the 
target message object's filter object chain. After delivering the message to the 
target message object, the object oriented message filtering unit automatically 
selectively routes the send MCB to postprocessor message objects associated with 
the target message object via the filter object chain. 

Server tasks receive messages from a port object by issuing a receive 
message request that includes a reference to the port object. After a server task 
receives a message, the server task performs a service corresponding to the 
particular message object to which ihe message had been delivered. The object 
oriented message filtering imit matches each send MCB with a receive message 
request. Because each preprocessor message object, target message object, and 
postprocessor message object is associated with a port object, the selective delivery 
of the send MCB to one or more preprocessor message objects facilitates message 
preprocessing services that may be required before the service associated with the 
target message object is performed. In a like manner, the selective delivery of the 
send MCB to one or more postprocessor message objects facilitates message 
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postprocessing services that may be required after the service associated with the 
target message object is performed. 

After a server task has performed a given service, the server task can issue a 
continue message request, a forward message request, or a reply. In the present 
5 invention, the transfer or rerouting of the send MCB to one or more preprocessor 
message objects associated with the target message object via the fiher object chain 
is referred to as "continuing" the message during preprocessing. In a like manner, 
the transferal or rerouting of the send MCB to one or more postprocessor message 
objects associated with the target message object via the filter object chain is 
10 referred to as continuing the message during postprocessing. The object oriented 
message filtering unit continues a message by performing continue message 
operations, in accordance with preprocessing or postprocessing, in response to a 
continue message request. The object oriented message filtering unit also 
"forwards" the send MCB to a new target message object by performing message 
15 forward operations in response to a forward message request. 

In response to a reply issued after a server task's performance of a service 
associated v^th a preprocessor message object, the object oriented message filtering 
unit routes the send MCB to a postprocessor message object associated vdth the 
preprocessor message object in a "skip-ahead" operation. In response to a reply 
20 issued after a server task's performance of a service associated with the target 
message object, the object oriented message filtering unit selectively routes Hie 
send MCB to postprocessor message objects associated with the target message 
object via the filter object chain. In response to a reply issued after all 
postprocessing has been considered, the object oriented message filtering tmit 
25 delivers a reply status and possibly data to the client task that originally sent the 
message. 

The method of the invention comprises the steps of; creating a port object; 
creating a target message object associated with the port object; creating a filter 
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object associated with the target message object; creating a preprocessor message 
object associated with the filter object; generating a imique message ID in response 
to a message transaction initiated by a send message request; creating a send 
message control block; and selectively routing the send message control block to 
5 the preprocessor message object prior to delivering the send message control block 
to the target message object. 

In the present invention, a client task issues a single send message request 
regardless of whether preprocessing or postprocessing services are required in 
addition to the service associated with the target message object. 

10 

BRIEF DESCRIPTION OF THE DRAWINGS 
Figure 1 is a block diagram of a preferred embodiment of system for object 
oriented message filtering constructed in accordance with the present invention; 
Figure 2 is a block diagram of an object oriented message filtering unit of 
15 the present invention; 

Figure 3 is a block diagram of a preferred object oriented message filtering 
model provided by the present invention; 

Figure 4 is a block diagram of a message object in the present invention; 
Figure 5 is a block diagram of a port object in the present invention; 
20 Figure 6 is a block diagram of a filter object in the present invention; 

Figxire 7A is a block diagram of a synchronous send message control block 
in the present invention; 

Figure 7B is a block diagram of an asynchronous send message control block 
in the present invention; 
25 Figure 8 A is a block diagram of a synchronous receive message control 

block in the present invention; 

Figure 8B is a block diagram of an asynchronous receive message control 
block in the present invention; 
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Figure 9 is a block diagram of a delivery message control block in the 
present invention; 

Figures lOA, lOB, and IOC are a flowchart of a preferred method for object 
oriented message filtering in accordance with the present invention; 
5 Figures llA, IIB, IIC, and IID are a flowchart of a preferred method for 

installing a new filter object into a filter object chain; 

Figure 12 is a flowchart of a preferred method for performing send message 
operations; 

Figure 13 is a flowchart of a preferred method for synchronizing with 
10 message object locking operations; 

Figure 14 is a flowchart of a preferred method for examining preprocessor 
message objects; 

Figures 15A, 15B, and 15C are a flowchart of a preferred method for 
performing low-level send message operations; 
15 Figures 16A, 16B, and 16C are a flowchart of a preferred method for 

performing continue message operations; 

Figures 17A, 17B, and 17C are a flowchart of a preferred method for 
performing forward message operations; 

Figures 18A and 18B are a flowchart of a preferred method for performing 
20 receive message operations; 

Figure 19A and 19B are a flowchart of a preferred reply method; 

Figure 20 is a flowchart of a preferred method for performing locking 
operations; and 

Figure 21 is a flowchart of a preferred method for performing uidocking 
25 operations. 
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DETAILED DESCRIPTrON OF THE PREFERRED EMBODIMENTS 
Referring now to Figure 1, a block diagram of a preferred embodiment of a 
system 10 for object oriented message filtering constructed in accordance with the 
present invention is shown. The system 10 comprises a processing unit 12, an 
5 input device 14, an output device 16, a predetermined amount of memory 18 
wherein an operating system 30, a client task 32, and a server task 34 reside. 
Preferably, the operating system 30 is a microkernel operating system 30 as 
described in U.S. Patent Application Serial No. 08/220,043. An object oriented 
message filtering imit 40 resides within the operating system 30. Each element of 
10 the system 10 has an input and an output coupled to a common system bus 29. In 
an exemplary embodiment, the system 10 of the present invention is an Apple 
Macintosh computer system made by Apple Computer, Inc., of Cupertino, CA, and 
having a Motorola MC68030 or later-generation microprocessor and 8 Mbytes of 
Random Access Memory (RAM) wherein a microkemel operating system 30 that 
15 includes the object oriented message filtering imit 40 resides. 

In the present invention, a client task 32 is preferably a set of program 
instructions that requires a given service, for example, the transfer of data from 
the external storage device 18 into the memory 20. The provider of a given 
service is referred to herein as a server task 34. Preferably, each server task 34 is 
20 also a set of program instructions. 

The object oriented message filtering xmit 40 facilitates the transfer of a 
message from a client task 32 to one or more server tasks 34 for processing. 
Referring now to Figure 2, a block diagram of a preferred embodiment of the 
object oriented message filtering imit 40 is shown. The object oriented message 
25 filtering unit 40 comprises an object management imit 42, a message transaction 
xmit 44, a locking unit 46, and an object database 48 wherein a filter object memory 
49 resides. Each element of the object oriented message filtering unit 40 has an 
input and an output coupled to the common system bus 29. 
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The object management imit 42 creates and maintains a set of objects or 
data structures in the memory 20 that provide an object oriented message filtering 
model 50. Referring now to Figure 3, a block diagram of a preferred object 
oriented message filtering model 50 is shown. In the preferred object oriented 
message filtering model 50, one or more target message objects 51 are present. 
Each target message object 51 preferably corresponds to a particular service 
provided by a server task 34. To invoke the behavior associated with a given 
target message object 51, a client task 32 sends a message to the target message 
object 51 by issuing a send message request, where the send message request 
specifies the target message object 51, a message, and a message type. The send 
message requests will be described in more detail below. A set of client tasks 32 
associated with a given target message object 51 is referred to herein as a client 
team 33. 

One or more filter objects 56 may be associated with a particular target 
message object 51. When a target message object 51 has an associated filter object 
56, the target message object 51 is referred to herein as being filtered. The set of 
filter objects 56 associated with a given target message object 51 is referred to 
herein as a filter object chain 57. Each filter object 56 represents a selective 
message interception means, where selectivity is preferably indicated according to 
a set of message types. Associated with each filter object 56 is either a preprocessor 
message object 52, a postprocessor message object 53, or both a preprocessor 
message object 52 and a postprocessor message object 53, A preprocessor message 
object 52 represents a particular service that is to be performed prior to a server 
task's performance of the service associated with the target message object 51. 
Similarly, a postprocessor message object 53 represents a particular service that is 
to be performed after a server task's performance of the service associated with the 
target message object 51. In the preferred embodiment, preprocessor message 
objects 52 and postprocessor message objects 53 may themselves be filtered. 
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In the preferred message filtering model 50, each target message object 51, 
each preprocessor message object 52, and each postprocessor message object 53 is 
cissociated with a port object 54. As shown in Figure 3, a preprocessor message 
object 52 and a postprocessor message object 53 need not be associated with the 
5 same port object 54. That is, each preprocessor message object 52 and each 

postprocessor message object 53 can be independently associated with a particular 
port object 54. Each port object 54 serves as a receptacle for messages directed to 
each target, preprocessor, and postprocessor message objects 51, 52, 53 that are 
associated with the port object 54. Server tasks 34 receive messages from a port 

10 object 54 by issuing receive message requests as will be described in more detail 
below. After receiving a given message, a server task 34 implements the service 
represented by the target, preprocessor, or postprocessor message object 51, 52, 53 to 
which the message was directed, according to details supplied in the message itself. 
In the object oriented message filtering model 50, a client task 32 issues a 

15 send message request to a particular target message object 51. If no filter object 56 
is associated with the target message object 51, messages are transferred from the 
client task 32 to a server task 34 as described in U.S. Patent Application Serial No. 
08/220,043. When the target message object 51 has an associated filter object 56, the 
present invention determines whether the first filter object 56 in the target 

20 message object's filter object chain 57 has an associated preprocessor message 

object 52 and whether the message type specified in the send message request falls 
within the set of message types associated with the first filter object 56. If a 
preprocessor message object 52 is associated with the first filter object 56 and the 
message types match, the present invention reroutes the message to the 

25 preprocessor message object 52 for preprocessing. If the first filter object 56 does 
not have an associated preprocessor message object 53, or if the message types do 
not match, the present invention sequentially selects and examines each filter 
object 56 in the filter object chain 57 in the manner described above. 
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When a message has been rerouted to a preprocessor message object 52, a 
server task 34 wUl perform the service associated with the preprocessor message 
object 52. After performing the service associated with a preprocessor message 
object 52, the present invention either: 1) sequentially selects and examines a next 
filter object 56 in the target message object's filter object chain 57 in the manner 
described above in the event that the server task 34 issues a message continuation 
request and another filter object 56 is present in the filter object chain 57; 2) routes 
the message to the target message object 51 for processing in the event that the 
server task 34 issues a message continuation request and no other filter objects 56 
are present in the filter object chain 57; 3) reroutes the message to a new target 
message object 51 for processing in the event that the server task 34 issues a 
message forward request specifying a new target message object 51; or 4) reroutes 
the message to a corresponding postprocessor message object 53 for postproces-sing 
in the event that the server task 34 issues a reply. 

When the message has been received at the target message object 51, a 
server task 34 will perform the service associated with the target message object 51. 
Following the server task's performance of the service associated with the target 
message object 51, the present invention determines whether the last filter object 
56 in the filter object chain 57 has an associated postprocessor message object 53 
and whether the message type specified in the send message request falls within 
the set of message types associated with the last filter object 56. If a postprocessor 
message object 53 is associated with the last filter object 56 and the message types 
match, the present invention reroutes the message to the postprocessor message . 
object 53 for postprocessing. If no postprocessor message object 53 is present, or if 
the message types do not match, the present invention sequentially selects and 
examines the previous filter object 56 in the filter object chain 57 in the manner 
described above. 
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In a maimer analogous to that for a preprocessor message object 52, a server 
task 34 will perform the service associated with a postprocessor message object 53 
when the message has been rerouted to the postprocessor message object 53. After 
performing the service associated with the postprocessor message object 53, the 
5 present invention sequentially selects and examines each remaining previous 
filter object 56 in the filter object chain 57 according to the presence of a 
postprocessor message object 53 and according to matching message types, in the 
maimer described above. 

Those skilled in the art recognize that a filter object chain 57 is 

10 traversed in a "forward" direction toward the last filter object 56 when 

preprocessor message objects 52 are under examination, and that the filter object 
chain 57 is traversed in a 'T^ackward" direction toward the first filter object 56 
when postprocessor message objects 53 are under examination. 

When a message has been rerouted to a new target message object 51 as a 

15 result of a server task's issuance of a forward message request, the present 
invention preferably examines each filter object 56 in the new target message 
object's filter object chain 57, first in view of preprocessing and then in view of 
postprocessing, in the manner described above for the original target message 
object 51. After examining each filter object 56 in the new target message object's 

20 filter object chain 57 in view of postprocessing, the present invention examines 
each filter object 56 in the original target message object's filter object chain 57 in 
view of postprocessing. 

After all filter objects 56 in the original target message object's filter object 
chain 57 have been examined in view of postprocessing, the present invention 

25 issues a reply to client task 32 that originally sent the message. Herein, the reply 
that is issued after all filter objects 56 have been examined in view of 
postprocessing is referred to as a final reply. The final reply provides the client 
task 32 with status information and possibly data. Additional material describing 
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the object oriented message filtering model 50 is provided in Appendix A. The 
sending of a given message by a client task 32, followed by transfer of the message 
to one or more preprocessor message objects 52, target message objects 51, and 
postprocessor message objects 53, followed by the issuance of the final reply to the 
5 message is referred to herein as a message transaction. Each of the operations 
performed during a message transaction will be described in greater detail below. 

In the preferred embodiment, target message objects 51, preprocessor 
message objects 52, and postprocessor message objects 53 are implemented with an 
identical structure, which is referred to herein as a message object 58. Those 
10 skilled in the art will recognize that in an alternate embodiment, target message 
objects 51, preprocessor message objects 52, and postprocessor message objects 53 
could each have their own distinct structure. Referring now to Figure 4, a block 
diagram of a preferred embodiment of a message object 58 is shown. Each message 
object 58 is preferably stored in the object database 48. The object management 
15 unit 42 creates a message object 58 and generates a unique message object 
identification (ID) in response to a server task's issuance of a message object 
creation request. The message object creation request preferably includes a 
reference constant specifying an initial state of the message object 58; a reference to 
a given port object 54 with which the message object 58 is to be associated; and a 
20 client team ID specifying a set of client tasks 32 with which the message object 58 is 
to be associated. Additionally, if the message object 58 is to be filtered, the message 
object creation request preferably specifies a reference to a first filter object 56 in a 
filter object chain 57. If the message object 58 is to be used as a preprocessor 
message object 52 or as a postprocessor message object 53, the message object 
25 creation request also specifies a unique filter object ID that identifies the filter 
object 56 with which the preprocessor or postprocessor message object 52, 53 is 
associated. 
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Within each message object 58, a first data field stores the message object ID 
generated by the object management imit 42 that tmiquely identifies the message 
object 58; a second data field stores the reference coxistant supplied by the server 
task 34, where the reference constant corresponds to the initial state of the message 
5 object 58; a third data field references the given port object 54 indicated in the 
message object creation request; a fourth data field specifies the client team ID 33 
included in the message object creation request; and a fifth data field references a 
next message object 58 associated with the given port object 54. The object 
management unit 42 does not assign a value to the fifth data field until a next 

10 message object 58 has been created. If the message object creation request specifies 
a reference to a first filter object 56 in a filter object chain 57 associated with the 
message object 58, a sixth data field stores the reference to the specified filter object 
56. In the event that the message object creation request specified a filter object ID, 
a seventh data field stores the specified filter object ID corresponding to flie filter 

15 object 56 with which the message object 58 is associated. In the preferred 
embodiment, the sixth and seventh data fields in the message object 58 are 
initially set to a nil value. The sixth data field in the message object 58 is 
initialized and updated upon filter object installation and removal. Filter object 
installation and removal be described in detail below. If the message object 58 

20 is a target message object 51, the sbcth data field stores a pointer to the associated 
filter chain 57. When the target message object 51 is first created, the sixth data 
field is assigned a nil value because no filter objects 56 have been installed upon 
the target message object 51 yet. 

The filter object ID stored in the seventh data field of the message object 58 

25 is used only by preprocessor and postprocessor message objects 52, 53. The seventh 
data field is initialized when the message object 58 is designated as a preprocessor 
message object 52 or as a postprocessor message object 53 during a filter object 
installation. 
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Referring now to Figure 5, a block diagram of a preferred embodiment of a 
port object 54 is shown. The object management imit 42 creates a port object 54 
and generates a unique port object ID in response to a port object creation request 
from a server task 34. In the port object 54, a first data field specifies a next port 
5 object and a previous port object. The object management uiut 42 therefore links 
port objects 52 together via their respective first data fields. A second data field in 
the port object 54 provides a list of those message objects 52 that are associated 
with the port object 54. When the object management unit 42 creates a new 
message object 58, the object management unit 42 adds the corresponding new 
10 message object ID to the list in the second data field of the port object 54 with 
which the newly created message object 58 is associated. A third data field in the 
port object 54 provides a list of each associated message object 58 that has been 
"locked" in response to a lock request. When a given message object 58 is locked, 
any messages directed to the given message object 58 are not available to be 
15 received by a server task 34 tmtil unlocking operations have been performed. 
Message object locking and imlocking operations are performed by the locking 
unit 46 and will be described in detail below. 

In the port object 54, a fourth data field is used to store a pending send 
message list that specifies those messages that have been directed to a message 
20 object 58 associated with the port object 54, but that have not yet been received by a 
server task 34. A fifth data field in the port object 54 is used to store a pending 
receive message list that specifies those receive message requests that have been 
issued to the port object 54 by server tasks 34, but that have not yet been matched 
to a corresponding message directed to a message object 58 associated with the port 
25 object 54. A sixth data field in the port object 54 is used to store a pending reply 
message list that specifies each message that server tasks 34 have received but for 
which a final reply has not yet been issued. When the object management unit 42 
creates the port object 54, the fourth, fifth, and sixth data fields are empty. As will 
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be described below, the lists stored in the fourth, fifth, and sixth data fields are 
maintained by the message transaction tmit 44. 

A seventh data field in the port object 54 optionally specifies an acceptance 
function and a set of message types associated with the acceptance function. 
5 Acceptance fimctions are described in detail in U.S, Patent Application Serial No. 
08/220,043. Preferably, the seventh data field is empty when the object 
management unit 42 first creates the port object 54. The object management unit 
42 stores or registers a reference to an acceptance function and the set of message 
types in response to a server task registration request that identifies a particular 

10 acceptance function and the set of message types. 

In the preferred embodiment, client tasks 32 can send messages 
synchronously or asjmchronously. In a like manner, server tasks can issue receive 
message requests synchronously or asynchronously. Synchronous and 
asynchronous operations will be described in more detail below. An eighth data 

15 field in the port object 54 specifies an amotmt of storage available for messages 
sent asynchronously, and a ninth data field in the port object 54 specifies an 
amount of storage available for asynchronous message receive requests. 

A tenth data field in the port object 54 is used to store the imique port object 
ID generated by the object management unit 42. Finally, an eleventh data field in 

20 the port object 54 is used to store statistical information such as the total number 
of messages sent to message objects 52 associated with the port object 54 since the 
port object's creation. In the preferred embodiment, each message object 58 is 
associated with a particular port object 54. Therefore, a port object 54 must be 
created in the preferred embodiment before a corresponding message object 58 is 

25 created. 

The object management imit 42 creates a new filter object 56, generates a 
imique filter object ID corresponding to the new filter object 56, and installs or 
inserts the new filter object 56 into a iSlter object chain 57 in response to an 
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installation request from a server task 34. In the preferred embodiment, the 
installation request specifies a filter object name that identifies the new filter 
object 56 according to a type of service associated with the new filter object 56; a 
message type list that specifies each type of message that a preprocessor message 
5 object 52 or a postprocessor message object 53 associated with the new filter object 
56 may perform operations upon; a placement order that indicates where the new 
filter object 56 is to be inserted or installed into a filter object chain 57; a 
preprocessor message object ID if a preprocessor message object 52 is to be 
associated with the new filter object 56; a postprocessor message object ID if a 
10 postprocessor message object 53 is to be associated with the new filter object 56; a 
target message object ID that identifies a target message object 51 with which the 
new filter object 56 is to be associated; and an optional set of installation options. 

In response to the installation request, the object management urut 42 
creates a new filter object 56 and generates a corresponding unique filter object ID. 
15 Referring now to Figure 6, a block diagram of a preferred embodiment of a filter 
object 56 is shown. Each filter object 56 is a data structure that includes a first data 
field storing the filter object ID; a second data field in which a reference to a next 
and to a previous filter object 56 in a filter object chain 57 are stored when the 
filter object 56 is installed into a filter object chain 57; a third data field storing the 
20 filter object name; a fourth data field storing the message type list; a fifth data field 
storing the placement order; a sixth data field storing a preprocessor message 
object ID in the event that the filter object 56 has an associated preprocessor 
message object 52; a seventh data field storing a postprocessor message object ID in 
the event that the filter object 56 has an associated postprocessor message object 53; 
25 an eighth data field storing the target message object ID; and a ninth data field 
storing the optionally-specified set of installation options. Each filter object 56 is 
stored in the filter object memory 49 within the object database 48. 
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After creating the new filter object 56 and generating the corresponding 
filter object ID, the object management imit 46 installs the filter object 56 into a 
given filter object chain 57 according to the specified placement order and 
installation options. In the preferred embodiment, each filter object's placement 
5 order preferably specifies a first filter object name and a second filter object name. 
When the filter object 56 is installed in a filter object chain 57, the first filter object 
name indicates that the filter object 56 is to be installed preceding a filter object 56 
in the filter object chain 57 that has the first filter object name; and the second 
filter object name indicates that the filter object 56 is to be installed following a 

10 filter object 56 in the filter object chain 57 that has the second filter object name. 
Thus, the first filter object name provides a '"before rule" for installation, and the 
second filter object name provides an "after rule" for installation. Preferably, the 
installation options specify a "right-before" option that indicates whether the filter 
object 56 is to be installed immediately before a filter object 56 in the filter object 

15 chain 57 that has the first filter object name. The installation options also 

preferably specify a "right-after" option that indicates whether the filter object 56 is 
to be installed immediately after a filter object that has the second filter object 
name. The detailed operations performed by the object management unit 42 
during filter object installation are described in detail below in the context of 

20 Figures llA, IIB, IIC, and IID. 

In addition to creating message objects 58, creating port objects 54, and 
creating and installing filter objects 56, the object management unit 42 provides to 
a server task 34 information associated with a given message object 58 in response 
to a message object examination request. The information provided includes the 

25 client team ID 33 specified in the given message object, a port object ID specifying 
the port object 54 with which the given message object 58 is associated, and the 
current value of the message object's reference constant. The object management 
unit 42 extracts the client team ID and the current value of the reference constant 
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from the message object 58 itself, and uses the port object address within the 
message object 58 to retrieve the port object ID from the port object 54 with which 
the message object 58 is associated. The object management unit 42 also modifies 
the above information in response to a message object modification request, and 
5 deletes a given message object 58 in response to a client team tennination 

message. Additionally, the object management unit 42 provides the filter object 
ID of each filter object 56 associated with a particular message object 58 in response 
to a filter object lookup request that specifies a message object ID. 

In a manner analogous to the operations provided for message objects 52, 
10 the object management tmit 42 provides information related to a port object 54 in 
response to a port object examination request from a server task 34, modifies data 
fields within the port object 54 in response to a port object modification request, 
and deletes port objects 52 in response to a port object deletion request. 

Similarly, the object management unit 42 provides information related to a 
15 filter object 56 in response to a filter object examination request from a server task 
34, provides the filter object ID of each filter object in a filter object chain 57 in 
resporise to a lookup request that specifies a target message object 51, and deletes a 
filter object 56 in response to a filter object deletion request. In the filter object 
deletion request, the object management imit 42 first removes the filter object 57 
20 from the filter chain 57 in which it resides, and then deletes the filter object 56 
itself. 

The message transaction imit 44 performs the operations required to cany 
out message transactions. In particular, the message transaction unit 44 performs 
the operations required to support the sending of messages from client tasks 32 to 
25 target message objects 51, the rerouting of messages to preprocessor message 

objects 52 or postprocessor message objects 53 associated with filter objects 56 in a 
filter object chain 57, the forwarding of messages to new target message objects 51, 
the issuance of receive message requests by server tasks 34, the matching of sent or 
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rerouted messages to issued receive message requests, the selective delivery of a 
message to an acceptance function or to a server task 34 to perform a service 
indicated by a message, and the transfer of replies from acceptance functions and 
server tasks 34 to client tasks 32. 
5 The message transaction unit 44 requires that client tasks 32 send messages 

to target message objects 51 by issuing send message requests. In the preferred 
embodiment, each send message request is either 1) a synchronous send message 
request; 2) a synchronous send-and-receive message request; 3) an as)Tichronous 
send message request; or 4) an asynchronous send-and-receive message request. 
10 As v^ill be described in detail below, in response to either type of synchronous 
send message request, the message transaction imit 44 blocks the sending client 
task 32 imtil the message transaction has completed, thereby preventing the client 
task 32 from performing other operations while the message transaction is in 
progress. In contrast, the message transaction unit 44 allows the sending client 
15 task 32 to continue other operations in response to either type of asynchronous 
send message request. Each type of send message request preferably specifies a 
target message object ID; a reference to a starting memory location at which a 
message begins; message length information; a message type that provides a 
categorization of the message; send options that indicate whether the message is to 
20 be delivered to an acceptance function or to a server task 34 by reference or by 
value; and a flag to indicate whether the message object 52 to which the send 
message request is directed is to be locked in response to the send message request 
and subsequently unlocked after an acceptance function or a server task 34 has 
replied to the message. Both synchronous and asynchronous send-and-receive 
25 message requests additionally specify a reply buffer address at which a server task 
can store a reply message or data, and a reply buffer size. In the preferred 
embodiment, the message type is a 32-bit number. 
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Each type of synchronous send message request also specifies a maximum 
time interval that the client task 32 can remain idle while the message transaction 
occurs. In addition to the information common to every send message request, 
each type of asynchronous send message request additionally specifies an address 
5 at v^hich the message transaction unit 44 can store a message ID signal 

corresponding to the asynchronous send message request, and event notification 
information that indicates hov^ the message transaction imit 44 is to notify the 
client task 32 when the message transaction is complete. In the description that 
follows, the message ID signal is simply referred to as the message ID. 
10 In response to a given client task's issuance of a send message request, the 

message transaction tmit 44 performs send message operations. The send message 
operations will be described in detail below in the context of Figure 12. During the 
send message operations, the message transaction imit 44 creates a send message 
control block (MCB) according to whether the send message request is 

15 synchronous or asynchronous. In response to a synchronous send message 
request or a synchronous send-and-receive message request, the message 
transaction imit 44 creates a synchronous send MCB 60. Referring now to Figure 
7A, a block diagram of a preferred embodiment of a synchronous send MCB 60 is 
shown. The synchronous send MCB 60 is a data structure including a first data 

20 field storing the target message object ID corresponding to the target message 
object 51 to which the synchronous send message is directed; a second data field 
storing a current filter object ID corresponding to a filter object 56 currently imder 
consideration vyrithin a filter object chain 57; a third data field storing a current 
message object ID corresponding to a message object 58 associated with the current 

25 filter object 56 and currently imder consideration either as the target message 
object 51, a preprocessor message object 52 or a postprocessor message object 53; a 
fourth data field storing a current port object ID identifying the port object 54 with 
which the current message object 58 specified in the third data field is associated; a 
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fifth data field storing a filter object stack 59 that identifies filter objects 56 
associated with previous target message objects 51 in the event that the message is 
forwarded to a new target message object 51; a sixth data field providing a 
reference to a next and to a previous entry in the current port object's pending 
5 send message list; a seventh data field specifying the client task ID corresponding 
to the client task 32 that issued the synchronous send message request; an eighth 
data field providing the starting address in the memory 20 at which an associated 
message is stored; a ninth data field providing the length of the message; a tenth 
data field indicating the message type specified in the synchronous send message 

10 request; an eleventh data field wherein the message ID is stored; a twelfth data 
field specifying the send options indicated in the synchronous send message 
request; a thirteenth data field that the message transaction unit 44 uses to 
reference an MCB corresponding to a matching receive message request; a 
fourteenth data field in which the message transaction imit 44 stores a server task 

15 ID after delivering the message to a server task 34; a fifteenth data field indicating 
whether the message corresponding to the S)mchronous send message request has 
been delivered to a server task 34; a sbcteenth data field indicating whether the 
message object 52 identified in the S5mchronous send request is locked; a 
seventeenth data field specifying the address of a reply buffer in the event that the 

20 send message request is a synchronous send-and-receive message request; a 
eighteenth data field providing a reply buffer size in the event that the send 
message request is a synchronous send-and-receive message request; a nineteenth 
data field indicating whether the sending client task 32 has been blocked as a result 
of a blocking request; and a twentieth data field specifying the maximum time 

25 interval that the sending client task 32 can remain idle during the message 

transaction. The message transaction unit 44 stores the synchronous send MCB 60 
in the object database 48. 
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If the send message request is an asynchronous send message request or an 
asynchronous send-and-receive message request, the message transaction unit 44 
creates an asynchronous send MCB 62 rather than a synchronous send MCB 60. 
Referring now to Figure 7B, a block diagram of an asynchronous send MCB 62 is 
5 shown. The asynchronous send MCB 62 is a data structure including a first 
through an eighteenth data field, each of which specifies information analogous 
to that specified in the first through eighteenth data fields in the synchronous 
send MCB 60 described above. In addition, the asynchronous send MCB 62 
includes a nineteenth data field wherein the message transaction unit 44 stores 
10 the event notification information specified in the asynchronous send message 
request or asynchronous send-and-receive message request. As in the case of the 
synchronous send MCB 60, the message transaction unit 44 stores the 
asynchronous send MCB 62 in the object database 48. 

During a message transaction, the message transaction unit 44 selectively 
15 routes the send MCB to one or more port objects 54, where each port object is 
associated with the target message object 51, a preprocessor message object 52, or a 
postprocessor message object 53 as will be described in detail below. After creating 
a send MCB, the message transaction unit 44 performs a set of operations referred 
to herein as examining preprocessor message objects 58. In the consideration of 
20 preprocessor message objects 52, the message transaction unit 44 determines 
whether the send MCB is to be routed to a port object 54 associated with a 
preprocessor message object 52. The detailed operations performed by the message 
transaction imit 44 in the examination of preprocessor message objects 52 are 
described below in the context of Figure 14. 
25 If the message transaction unit 44 determines that the send MCB is to be 

routed to a port object 54 associated with a preprocessor message object 52 or a 
postprocessor message object 53, the message transaction unit 44 performs forward 
message operations. In the forward message operations, the message transaction 
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unit 44 generates an up-todate send MCB according to the port object 54 associated 
with the current message object 52 as given by the current message object ID in the 
third data field of the send MCB. The forward message operations will be 
described in detail below in the context of Figures 17 A, 17B, and 17C. 

In order to route a send MCB to a particular port object 54, the message 
transaction unit 44 performs low-level send operations as will be described in 
detail below in the context of Figures 15A, 15B, and 15C. Herein, the low-level 
send operations are identical to a subset of the send message operations described 
in U.S. Patent Application Serial No. 08/220,043. 

In the present invention, a server task 34 can process a message only after 
the message has been received from a port object 54. The message transaction unit 
44 requires that a server task 34 issue a receive message request to receive a 
message from a given port object 54. Receive message requests are either 
synchronous receive message requests, or asynchronous receive message requests. 
Each type of receive message request specifies a port object 54; a message type 
indicating a category of message the server task 34 is to receive; a reference to a 
memory location at which a message buffer begins; and a message buffer size. In 
the preferred embodiment, the message type is a 32-bit number. A synchronous 
receive message request further includes a maximimi time interval the issuing 
server task 34 can remain idle prior to the delivery of a message by the message 
transaction imit 44. In addition to the information common to both synchronous 
and asynchronous receive message requests, an as3nichronous receive message 
request further specifies a message address at which a receive ID corresponding to 
the asynchronous receive message request can be stored; and event notification 
information that the message transaction unit 44 uses to notify the issuing server 
task 34 that a message corresponding to the as5mchronous receive message request 
has been delivered. 
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In response to a receive message request, the message transaction unit 44 
performs receive message operations, which v^ill be described in detail below in 
the context of Figures 18A and 18B. During the receive message operations, the 
message transaction unit 44 creates a receive MCB if no send MCB having a 
message type matching that given in the receive message request is referenced in 
the pending send message list of the port object 54 to which the receive message 
request is directed. In other words, the message transaction unit 44 creates a 
receive MCB if the receive message request carmot be immediately matched to an 
existing send MCB. The receive MCB created by the message transaction unit 44 is 
either a synchronous or an asynchronous receive MCB 70, 72, according to 
whether the receive message request is a s}mchronous or an asynchronous receive 
message request, respectively. Referring now to Figure 8A, a block diagram of a 
preferred embodiment of a synchronous receive MCB 70 is shown. The 
synchronous receive MCB 70 is a data structure including a first data field 
specifying the port object ID corresponding to the port object 54 to which the 
synchronous receive message request is directed; a second data field referencing a 
next and a previous entry in the pending receive message list of the port object 54 
indicated in the first data field; a third data field wherein the message transaction 
unit 44 stores a server task ID corresponding to the server task 34 that issued the 
request; a fourth data field specifying the message buffer address included in the 
synchronous receive message request; a fifth data field specifying the message 
buffer size contained in the synchronous receive message request; a sixth data field 
providing the message type included in the synchronous receive message request; 
a seventh data field that the message transaction tmit 44 uses to reference an MCB 
corresponding to a send message request that matches the S5nichronous receive 
message request according to message type; and an eighth data field wherein the 
message transaction imit 44 stores the maximum time interval the issuing server 
task 34 can remain idle as specified in the synchronous receive message request. 
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The message transaction unit 44 stores the synchronous receive MCB 70 in the 
object database 48. 

Referring now to Figure 8B, a block diagram of a preferred embodiment of 
an asynchronous receive MCB 72 is shown. The as)nichronous receive MCB 72 is 
5 a data structure including a first through a seventh data field that specify 

information analogous to that detailed for the synchronous receive MCB 70. The 
asynchronous receive MCB 72 also includes an eighth data field wherein the 
message transaction tmit 44 stores the receive ID, and a ninth data field wherein 
the message transaction unit 44 stores the event notification information specified 

10 in the asynchronous receive message request. As in the case of each synchronous 
receive MCB 70, the message transaction imit 44 stores each as5nichronous receive 
MCB 72 in the object database 48. 

In the preferred embodiment, each MCB 60, 62, 70, 72 described above is 
implemented as a general MCB structure (not shown) plus one or more data fields 

15 that supply request-specific information. The general MCB structure includes data 
fields for specifying a port object 54; a client or server task 32, 34; references to 
other corresponding MCB structures; and state information specifying whether 
the general MCB structure corresponds to a synchronous or asynchronous request 
and whether the general MCB structure corresponds to a send or receive request. 

20 Those skilled in the art will be able to determine the specific additional data fields 
necessary to implement a synchronous MCB 60, an asynchronous send MCB 62, a 
synchronous receive MCB 70, and an asynchronous receive MCB 72 according to 
the descriptions provided above. 

The message transaction tmit 44 selectively matches a receive message 

25 request with a send MCB. The message transaction unit 44 selectively matches a 
send MCB either with an acceptance function or with a receive MCB associated 
with a port object 54 corresponding to a target message object 51, a preprocessor 
message object 52, or a postprocessor message object 53 as will be described in detail 
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below. Matching occurs according to the message types specified in a send message 
request and a receive message request, or according to the message type specified 
in a send message request and the set of message types associated with an 
acceptance function. In the preferred embodiment, the message transaction unit 
5 44 performs a logical AND operation to determine whether message types match. 

After routing a send MCB to a given port object 54, the message transaction 
xmit 44 may determine that the send MCB can be immediately serviced by a 
matching acceptance function or that the send MCB can be immediately serviced 
by a matching pending receive MCB. The message transaction unit 44 may also 
10 determine that the send MCB cannot be immediately serviced and must therefore 
become a pending send MCB. The message transaction unit 44 categorizes the 
send MCB as pending by inserting a reference to the send MCB into the pending 
send message list of the port object 54 identified in the send MCB. The message 
transaction unit 44 preferably maintains the pending send message list of the port 
15 object 54 as a doubly-linked list in first-in first-out (FIFO) order. 

In response to a given receive message request, the message transaction 
unit 44 may determine that the receive message request can be immediately 
matched to a pending send MCB, or that the receive message request cannot be 
immediately matched to a send MCB and must therefore become a pending 
20 receive message request. The message transaction imit 44 categorizes a receive 
message request as pending by creating a receive MCB and by inserting a reference 
to the corresponding receive MCB in the pending receive message list of the port 
object 54 identified in the receive MCB. As with the pending send message list, 
the message transaction unit 44 preferably maintains the pending receive message 
25 list as a doubly-linked list in FIFO order. When the message transaction unit 44 
categorizes a synchronous receive message request as pending, the message 
transaction unit 44 also blocks the execution of the server task 34 that issued the 
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synchronous receive message request until a matching send MCB arrives at the 
port object 54. 

When the message transaction unit 44 matches a send MCB to a receive 
MCB, or matches a receive message request to a send MCB, the message 
5 transaction imit 44 creates a delivery MCB 80. Referring now to Figure 9, a block 
diagram of a delivery MCB 80 is shown. The delivery MCB 80 is created from a 
subset of the data fields within the send MCB. The delivery MCB 80 includes a 
first data field in which the message ID specified in the send MCB is stored; a 
second data field specifying the reference constant of the current message object 58 

10 specified in the send MCB; a third data field in which the send options specified in 
the send MCB are stored; a fourth data field providing the message type given in 
the send MCB; a fifth data field in which the message location specified in the 
send MCB is stored; a sixth data field in which the message length specified in the 
send MCB is stored; a seventh data field in which any reply buffer address 

15 specified in the send MCB is stored; an eighth data field in which any reply buffer 
size specified in the send MCB is stored; and a ninth data field in which current 
results obtained from preprocessing, processing, and /or postprocessing during the 
message transaction can be stored. Preferably, when the delivery MCB 80 is first 
created, the current results are set to "incomplete." As detailed in U.S. Patent 

20 Application Serial No. 08/220,043, a server task 34 or an acceptance function 
obtains the message specified vrithin the delivery MCB 80 and performs the 
service indicated by the message. 

When a server task 34 has completed a service associated with a given port 
object 54, the server task 34 may issue a continue message request, a forward 

25 message request, or a reply. A continue message request preferably specifies a 
message ID. In response to a continue message request, the message transaction 
xmit 44 performs continue message operations. As will be described in detail in 
the context of Figures 16A, 16B, and 16C, in the continue message operations, the 
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message transaction unit 44 determines whether the message can be transferred to 
another filter object 56 in the current message object's filter object chain 57 
according to a filter object chain scan direction. If the most-recent operation 
performed upon the message are associated with a preprocessor message object 52, 
the message trarisaction imit 44 scans the filter object chain 57 in a "forward" 
direction towards the last filter object 56 in the filter object chain 57 to identify a 
next filter object 56 to examine. If the most-recent operation performed upon the 
message are associated with a postprocessor message object 53, the message 
transaction unit 44 scans the filter object chain 57 in a "backward" direction 
towards the first filter object 56 in the filter object chain 57 to identify a previous 
filter object 56 to examine. If the message can be transferred to another filter object 
56 in the current message object's filter object chain 57, the message transaction 
imit 44 performs the forward message operations. Thus, the continue message 
operations selectively result in the "continuation" of preprocessing or 
postprocessing from one filter object 56 to another filter object 56 within the filter 
object chain 57. 

In response to a forward message request, the message transaction imit 44 
performs the forward message operations referred to above and described in 
Figures 17A, 17B, and 17C. Each forward message request preferably specifies a 
message ID and a target message object 51. When the target message object 51 is 
specified in the forward message request is different from that stored in the send 
MCB corresponding to the message ID, the forward message operations result in 
the generation of an up-to-date send MCB that has the newly-specified target 
message object ID stored in the first data field. Additionally, a reference to each 
filter object associated with the original target message object 51 is stored in the 
filter object stack within the up-to-date send MCB. 

In response to a reply, the message transaction unit 44 performs reply 
operations. Each reply preferably specifies a message ID, and may optionally 
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specify a set of current results. In the reply operations, the message transaction 
unit 44 determines whether the reply has been issued by a server task 34 associated 
with a preprocessor message object 52. If so, the message transaction unit 44 routes 
the send MCB corresponding to the message ID to the postprocessor message 
5 object 53 associated with the preprocessor message object 52, thereby "skipping" 
each remaining filter object 56 in view of preprocessing, skipping the target 
message object 56, and skipping postprocessor message objects 56 associated with 
the skipped filter objects 56. The message transaction imit's routing of the send 
MCB from a filter object's associated preprocessor message object 52 to the filter 
10 object's associated postprocessor message object 53 is referred to herein as a skip- 
ahead operation. 

If no skip-ahead operation is required, the message transaction xmit 44 
determines whether each filter object 56 associated with the target message object 
51 has been exairuned in view of postprocessing. If not, the message transaction 

15 unit 44 performs continue message operations. If each filter object 56 associated 
with the target message object 51 has been examined, the message transaction unit 
44 issues a final reply to the client task 32 that originally sent the message, where 
the final reply provides the client task 32 with status information and possibly 
data. The reply operations are described below in detail in the context of Figures 

20 19Aandl9B, 

In response to a combined receive-and-reply message request issued by a 
server task 34, the message transaction unit 44 first performs reply operations as 
described above, and then performs receive message operations as described 
above. 

25 The locking imit 46 performs message object locking and tmlocking 

operatioris. In the preferred embodiment, locking and imlocking operations are 
performed in response to a lock request or an imlock request, respectively, issued 
by a server task 34 or by the message transaction tmit 44. A send message request 
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or a send MCB directed to a particular message object 58 after the message object 58 
has been locked is not eligible to be matched to an acceptance function or to a 
receive MCB imtil unlocking operations have been performed. In the preferred 
embodiment, lock requests can be issued by a server task 34, or by the message 
5 transaction unit 44 on behalf of a client task 32 as a result of a send message 

request. Preferably, each lock request specifies the message object ID of a message 
object 58 targeted for locking. The locking and unlocking operations are described 
in detail below in the context of Figures 20 and 21, respectively. 

During send message operations and forward message operations, the 
10 message transaction unit 44 synchronizes with locking operations. In 

synchronizing with locking operations, the message transaction unit 44 blocks the 
client task 32 that sent a message in the event that the current message object 58 to 
which the message has been directed is locked. The message transaction unit 44 
also locks the target message object 51 in the event that the send MCB specifies 
15 that the target message object 51 is to be locked. The detailed operations 

performed by the message transaction imit 44 in synchronizing with locking 
operations are described in detail below in the context of Figure 13. 

The detailed operations performed by the system 10 of the present 
invention during object oriented message filtering are now described as 
20 individual method steps in Figures lOA through Figure 21. Referring now to 
Figures lOA, lOB, and IOC, a flowchart of a preferred method for object oriented 
message filtering is shown. The preferred method begins in step 100 with the 
object management unit 42 determining whether a port object 54 is to be created, 
modified, examined, or deleted in response to a corresponding server task request. 
25 If a port object 54 is to be created, modified, examined, or deleted, the object 

management unit 42 performs the appropriate operation indicated by the server 
task request in step 102. After step 102 or after step 100, the object management 
unit 42 determines in step 104 whether a message object 52 is to be created. 
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modified, examined, or deleted in response to a corresponding server task request. 
If so, the object management unit 42 performs the action indicated by the server 
task request in step 106. Follovraig step 106 or step 104, the object management 
imit 42 determines v^hether a filter object 56 is to be installed, examined, looked- 
5 up, or deleted in step 108 in response to a server task request. If a filter object 56 is 
to be installed, examined, looked-up, or deleted, the object management unit 42 
performs the operation required by the server task request in step 110. After step 
110 or after step 108, the locking imit 46 determines in step 112 whether a message 
object 52 is to be locked in response to a server task lock request. If so, the locking 

10 tmit 46 performs the locking operations indicated in the server task request in step 
114. If in step 108 the locking unit 46 determines that no message object 52 is to be 
locked, or after step 114, the locking imit 46 next determines in step 116 whether a 
message object 52 is to be imlocked in response to a server task imlock request. If 
so, the locking tmit 46 performs the unlocking operations in response to the 

15 imlock request in step 118. If no message object tmlocking is required in step 116, 
or foUovsring step 118, the object management unit 42 determines in step 120 
whether an acceptance function is to be registered for a port object 54 in response 
to a server task request. If an acceptance function is to be registered, the object 
management unit 42 registers the acceptance function with the port object 54 

20 specified in the server task request in step 122. Step 122 is performed according to 
the registration of acceptance functions as described in U.S. Patent Application 
Serial No. 08/220,043. 

Follovraig step 118, or after step 116 if the object management imit 42 
determines that no acceptance function is to be registered, the message transaction 

25 unit 44 determines in step 130 whether a client task 32 has issued a send message 
request. If so, the message transaction unit 44 performs send message operations 
in step 132. After step 132, or after step 130 if no send message request has been 
issued, the message transaction unit 44 determines in step 134 whether a server 
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task has issued a continue message request. If a server task 34 has issued a 
continue message request, the message transaction unit 44 performs continue 
message operations in step 136. After step 136, or after step 134, the message 
transaction unit 44 determines whether a server task 34 has issued a forward 
5 message request in step 138. If a server task 34 has issued a forward message 
request, the message transaction unit 44 performs forward message operations in 
step 140. Following step 140, or after step 138, the message transaction unit 44 
determines in step 142 whether a server task 34 has issued a receive message 
request. If a server task 34 has issued a receive message request, the message 
10 transaction imit 44 performs receive message operations in step 144. If in step 132 
the message transaction imit 44 determines that no receive message request has 
been issued, or after step 134, the message transaction unit 44 determines in step 
150 whether a reply has been issued. If so, the message transaction unit performs 
reply operations in step 152. Following step 152, or following step 150 if no reply 
15 has been issued, the message transaction imit 44 determines whether a server task 
34 has issued a combined receive-and-reply message request in step 154. If so, the 
message transaction imit 44 performs the reply operations indicated in the 
receive-and-reply message request in step 156, after which the message transaction 
unit 44 performs receive message operations corresponding to the receive-and- 
20 reply message request in step 158. After step 158, or after step 154 if step 156 is not 
performed, the message transaction imit 44 determines whether operation is to 
terminate in step 160. If operation is to continue, the preferred method proceeds 
to step 100. Otherwise, the preferred method ends. 

Referring now to Figures llA, IIB, IIC, and IID, a flowchart of a preferred 
25 method for installing a new filter object 56 into a filter object chain 57 (step 110 of 
Figure lOA) is shovm. The preferred method begins in step 200 with the object 
management unit 42 generating a new filter object ID and creating a new filter 
object 56 in response to an installation request issued by a server task 34. Next, in 
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Step 202, the object management unit 42 locks each preprocessor and postprocessor 
message object 52, 53 associated with the target message object specified in the 
installation request. After step 202, the object management imit 42 determines 
whether the new filter object name is unique among all filter objects in the filter 
5 object chain 57. If the new filter object name is not unique, the object 

management imit 42 imlocks the preprocessor and postprocessor message objects 
52, 53 in the filter object chain in step 205, and then returns an installation failure 
error in step 206. After step 206, the preferred method ends. 

If the new filter object name is imique among all filter objects in the filter 

10 object chain 57 in step 204, the object management imit 42 next determines in step 
208 whether another filter object 56 is present in the filter object chain 57 in a 
forward direction in step 208. If another filter object 56 is not present in the filter 
object chain 57, the object management unit 42 determines in step 209 whether the 
filter object chain 57 is empty. If the filter object chain 57 is empty, the preferred 

15 method proceeds to step 276. 

If the object management imit 42 determines in step 208 that another filter 
object 56 is present in the filter object chain 57, the object management unit 42 
selects a next filter object 56 in step 210, Next, in step 212, the object management 
imit 42 determines whether the new filter object's before rule matches the selected 

20 filter object name. If so, the object management unit 42 stores the position of the 
selected filter object in the filter object chain 57 in step 214. If the new filter object's 
before rule does not match the selected filter object name in step 212, the object 
management unit 42 next determines in step 216 whether the selected filter 
object's after rule matches the new filter object name. If so, the preferred method 

25 proceeds to step 214. If the selected filter object's after rule does not match the new 
filter object name, the preferred method returns to step 208. 

After step 214, or after step 209 in the event that the filter object chain 57 is 
not empty^ the object management imit 42 determines whether another filter 
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object 56 is present in the filter object chain 57 in step 230. If so, the object 
management unit 42 selects the next filter object in step 232. Next, the object 
management unit 42 determines whether the new filter object's after rule matches 
the selected filter object name in step 234. If so, the object management unit 42 
5 determines in step 235 whether the match specifies an impossible filter object 
chain ordering. If the match specifies an impossible filter object chain ordering, 
the preferred method returns to step 205. 

After step 235, or after step 234, the object management unit 42 determines 
whether the selected filter object's before rule matches the new filter object name 
10 in step 236. If so, die object management imit 42 determines in step 237 whether 
the match specifies an impossible filter object chain ordering. If the match 
specifies an impossible filter object chain ordering, the preferred method returns 
to step 205. 

After step 237, or after step 236, the object management unit 42 determines 
15 whether the selected filter object's installation options specify that the selected 
filter object 56 is to be immediately after the new filter object 56 in the filter object 
chain 57 in step 238. If the selected filter object's installation options specify that 
the selected filter object 56 is to immediately follow the new filter object 56, the 
object management imit 42 determines in step 239 whether this ordering is 
20 impossible. If so, the preferred method returns to step 205. 

After step 239, or after step 238, the object management vadt 42 determines 
in step 240 whether the new filter object's installation options specify that the new 
filter object 56 is to be immediately before the selected filter object 56 in the filter 
object chain 57. If the new filter object's installation options specify fliat the new 
25 filter object 56 is to immediately precede the selected filter object 56, the object 
management unit 42 determines in step 241 whether fliis ordering is impossible. 
If so, the preferred metiiod returns to step 205, 
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If in step 230 the object management imit 42 determines that another filter 
object 56 is not present in the filter object chain 57, the object management unit 42 
selects the first filter object 56 in the filter object chain 57 in step 242. After step 
242, the object management imit 42 determines whether the position of the 
5 selected filter object 56 in the filter object chain 57 is the match position that was 
stored in step 214. If not, the object management tmit 42 determines in step 252 
whether the selected filter object's placement order specifies that the selected filter 
object 56 is to follow the new filter object 56 in the filter object chain 57. If the 
selected filter object's placement order specifies that the selected filter object 56 is to 

10 follow the new filter object 56 in the filter object chain 57, the object management 
unit 42 next determines in step 253 whether this ordering is impossible. If so, the 
preferred method proceeds to step 260. In step 260, the object management imit 42 
resets the match position that was stored in step 214, after which the preferred 
method returns to step 230. 

15 After step 253, or after step 252, the object management xmit 42 determines 

whether the selected filter object's installation options specify that the selected 
filter object 56 is to immediately precede the new filter object 56 in the filter object 
chain 57. If the selected filter object's installation options specify that the selected 
filter object 56 is to immediately precede the new filter object 56 in the filter object 

20 chain 57, the object management imit 42 determines in step 255 whether this 
ordering is impossible. If so, the preferred method proceeds to step 260. 

After step 255, or after step 254, the object management unit 42 determines 
in step 256 whether the new filter object's installation options specify that the new 
filter object 56 is to immediately follow the selected filter object 56 in the filter 

25 object chain 57. If the new filter object's installation options specify that the new 
filter object 56 is to immediately follow the selected filter object 56 in the filter 
object chain 57, the object management unit 42 determines in step 257 whether 
this ordering is impossible. If so, the preferred method proceeds to step 260. 
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After step 257, or after step 256, the object management unit 42 selects the 
next filter object 56 in the filter object chain 57, after which the preferred method 
returns to step 250. 

If in step 250 the determines that the match position that was stored in step 
214 has been reached, the object management unit 42 next determines whether the 
new filter object 56 is to be installed between two filter objects 56 in the filter object 
chain 57. If so, the object management imit 42 determines in step 272 whether the 
right-before option in the filter object 56 before which the new filter object 56 is to 
be inserted can be satisfied. If the right-before option cannot be satisfied, the 
preferred method returns to step 205. If the right-before option can be satisfied, the 
object management imit 42 next determines in step 274 whether the right-after 
option in the filter object 56 after which the new fUter object 56 is to be inserted 
can be satisfied. If the right-after option in the filter object 56 after which the new 
filter object 56 is to be inserted carmot be satisfied, the preferred method returns to 
step 205. 

After step 274, the object management unit 42 modifies the second data field 
in the new filter object 56 such that it references the appropriate next and previous 
filter objects 56 in the filter object chain 57 in step 276. The object management 
imit 42 also modifies the second data fields in the filter objects 56 immediately 
preceding and immediately following the location at which the new filter object 56 
is to be positioned in the filter object chain 57 in a like manner. The performance 
of step 276 effectively makes the new filter object a part of the filter object chain 57. 
After step 276, the object management tinit 42 unlocks each preprocessor and 
postprocessor message object 52, 53 associated with the filter object chain 57 in step 
278, after which the preferred method ends. 

Referring now to Figure 12, a flowchart of a preferred method for 
performing send message operations (step 132 of Figure lOB) is shown. The 
preferred method begins in step 300 with the message transaction unit 44 decoding 
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the target message object ID specified in the corresponding send message request. 
Next, the message transaction imit 44 determines whether the target message 
object ID is valid in step 302. If the target message object ID is not valid, the 
message transaction unit 44 returns an invalid ID error in step 304, after which the 
5 preferred method ends. If the target message object ID is valid, the message 
transaction unit 44 synchronizes with message object locking operations in step 
306. Next, the message transaction unit 44 generates a imique message ID and 
creates a send MCB in step 308. Preferably, the message transaction unit 44 
associates ttie send MCB with the message ID, such that the send MCB can be 
10 uniquely identified and located by the message ID. If the send message request is a 
synchronous send message request, the message transaction imit 44 creates a 
synchronous send MCB 60. If the send message request is an as5mchronous send 
message request, the message transaction imit 44 creates an asynchronous send 
MCB 62. 

15 After step 308, ttie message transaction unit 44 identifies the target message 

object as the current message object under consideration in step 310 by storing the 
target message object ID specified in the first data field of the send MCB into the 
third data field of the send MCB. Next, in step 312, the message transaction unit 44 
examines preprocessor message objects 52. The examination of preprocessor 

20 message objects 52 is described in detail below with reference to Figure 14. After 
step 312, the message transaction xmit 44 identifies the port object 54 associated 
with the target message object 51 as the current port object 54 in step 314 by storing 
the corresponding port object ID in the fourth data field of the send MCB. The 
message transaction unit 44 then performs low-level send message operations in 

25 step 316, after which the preferred method ends. 

Referring now to Figure 13, a flowchart of a preferred method for 
synchronizing with locking operations (step 300 of Figure 12) is shown. The 
preferred method begins in step 400 with the message transaction unit 44 
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detenriining whether the current message object 58 is locked. If the current 
message object 58 is locked, the message transaction xmit 44 blocks the client task 
32 indicated in the send MCB by preventing the client task 32 from performing 
further operations in step 402. Client task blocking is performed in a conventional 
5 manner. After step 402, or after step 400, the message transaction imit 44 

determines in step 404 whether the current message object 58 is to be locked by 
examirung the send options specified in the send MCB. If the current message 
object 58 is to be locked, the message transaction imit 44 locks the current message 
object 58 in step 406. After step 406, or after step 404, the preferred method ends. 
10 Referring now to Figure 14, a flowchart of a preferred method for 

examining preprocessor message objects 52 (step 312 of Figure 12 and step 838 of 
Figure 17C) is shown. The preferred method begins in step 500 with the message 
transaction unit 44 determining whether another filter object 56 is referenced in 
the filter object chain 57 associated with the current message object 58. If another 
15 filter object 56 is not referenced by the current message object 58, the preferred 
method ends. If another filter object 58 is referenced in the filter object chain 57 
associated with the current message object 58, the message transaction imit 44 
selects the next filter object 56 in the filter object chain 57 in step 502. After step 
502, the message transaction xmit 44 determines in step 504 whether the selected 
20 filter object 56 has an associated preprocessor message object 52 by examining the 
sixth data field in the selected filter object 56. If the selected filter object 56 does not 
have an associated preprocessor message object 52, the preferred method returns 
to step 500. If the selected filter object 56 has an associated preprocessor message 
object 52, the message transaction unit 44 next determines in step 506 whether the 
25 message type specified in the send MCB matches a message type given in the 
selected filter object's message type list. If the message type specified in the send 
MCB does not match a message type in the selected filter object's message type list, 
the preferred method returns to step 400. If the message type specified in the send 
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MCB matches a message type in the selected filter object's message type list, the 
message transaction imit 44 next determines whether the current message object 
58 is locked in step 508. If the current message object 58 is locked, the message 
transaction xmit 44 unlocks the current message object 58 in step 510. After step 
5 510, or after step 508, the message traiisaction unit 44 identifies the preprocessor 
message object 52 associated with the selected filter object 56 as the current 
message object in step 512 by storing the message object ID associated with the 
preprocessor message object 52 in the third data field of the send MCB. The 
message transaction unit 44 then identifies the selected filter object 56 as the 

10 current filter object 56 in step 514 by storing the corresponding filter object ID in 
the second data field of the send MCB. After step 514, the message transaction imit 
44 performs forward message operations in step 516, Forward message operations 
are described in detail below with reference to Figures 17A, 17B, and 17C. 
Following step 516, the preferred method ends. 

15 Referring now to Figures 15A, 15B, and 15C, a flowchart of a preferred 

method for performing low-level send operations (step 316 of Figure 12 and step 
840 of Figure 17C) is shown. The preferred method begins in step 600 with the 
message transaction urut 44 determining whether an acceptance function 
specifying a message type tfiat matches the message type in the send MCB has been 

20 registered with the current port object 54 specified in the send MCB. If an 

acceptance function has been registered, the message transaction xmit 44 creates a 
delivery MCB 80 in the client task's address space in step 602. Following step 602, 
tiie message transaction unit 44 passes a pointer to the delivery MCB 80 to the 
acceptance function in step 604, Next, the message transaction imit 44 inserts a 

25 reference to the send MCB in flie pending reply message list within the current 
port object 54 in step 606. 

After step 606, the message transaction imit 44 determines whether the send 
MCB created is a synchronous send MCB 60 in step 640 of Figure 15C. If not, the 
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message transaction unit 44 returns the message ID to the client task 32 that issued 
the send message request in step 642, after which the preferred method ends. If 
the send MCB is a synchronous send MCB 60, the message transaction xmit 44 next 
prevents the sending client task 32 from performing further operations, that is, 
5 blocks the sending client task 32, in step 644. Next, in step 646, the message 

transaction unit 44 determines whether the maximum time interval specified in 
the send MCB has been exceeded. If so, the message transaction imit 44 returns a 
timeout status to the sending client task 32, after which the preferred method 
ends. If the maximimi time interval has not been exceeded, the message 
10 transaction unit 44 determines whether a reply has been issued to the message 
indicated in the send message request in step 648. If no reply has been issued, the 
preferred method returns to step 646. If in step 648 the message transaction unit 44 
determines that a reply has been issued, the message transaction unit 44 performs 
reply operations in step 650. Following step 650, the preferred method ends. 
15 If in step 600 the message transaction imit 44 determines that a matching 

acceptance function is not present, the message transaction unit next determines 
whether a matching receive MCB is present in the current port object's pending 
receive message list in step 608. If a matching receive MCB is not present, the 
message transaction unit 44 inserts a reference to the send MCB in the current port 
20 object's pending send message list in step 610, after which the preferred method 
proceeds to step 640. If the message transaction imit 44 determines that a 
matching receive MCB is present in step 608, the message transaction unit 44 
creates a delivery MCB at the message buffer address specified within the 
matching receive MCB in step 620 of Figure 15B. Next, the message transaction 
25 imit 44 inserts a reference to the send MCB in the current port object's pending 
reply message list in step 622. Following step 622, the message transaction unit 44 
determines in step 624 whether the receive MCB is a synchronous receive MCB 70. 
If so, the message transaction imit 44 unblocks the receiving server task 34 that 
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issued the corresponding receive message request in step 630. If the message 
transaction unit 44 determines that the receive MCB is not a synchronous receive 
MCB 70, the message transaction unit 44 delivers the message referenced in the 
send MCB to the server task 34 identified in the asynchronous receive MCB 72 in 
5 step 626. Following step 626, the message transaction unit 44 notifies the receiving 
server task 34 according to the event notification information specified in the 
asynchronous receive MCB 72 in step 628. After step 628, or after step 630, the 
message transaction vmit 44 deletes the receive MCB and its corresponding 
pending receive message list reference in step 632. Following step 632, the 
10 preferred method proceeds to step 640. 

Referring now to Figures 16A, 16B and 16 C, a flowchart of a preferred 
method for performing continue message operations (step 136 of Figure lOB and 
step 1018 of Figure 19A) is shown. The preferred method begins in step 700 with 
the message transaction unit 44 decoding tiie message ID specified in tiie continue 
15 message request. Next, the message transaction unit 44 determines whether the 
message ID is valid in step 702. If the message ID is not vaUd, the message 
transaction unit 44 returns an invalid ID error in step 710, after which tiie 
preferred method ends. If the message ID is valid, the message transaction unit 44 
next locates the corresponding send MCB in step 704, after which the message 
20 transaction unit decodes the current message object ID specified in the third data 
field of the send MCB in step 706. Following step 706, the message transaction 
unit 44 determines whether the current message object ID is valid in step 708. If 
not, the message transaction unit 44 returns an invalid ID error in step 710, after 
which flie preferred metfiod ends. If the current message object ID is valid, the 
25 message transaction unit 44 determines the filter object chain scan direction in 
step 712. In determining the filter object chain scan direction, the message 
transaction unit 44 determines whether the current message ID stored in the send 
MCB matches the preprocessor message object ID stored in the current filter object 
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56. If the current message ID stored in the send MCB matches the preprocessor 
message object ID stored in the current filter object 56, the filter object chain scan 
direction is forward. Otherwise, the filter object chain scan direction is backward. 
If the filter object chain scan direction is forward, the message is to be routed either 
5 to a preprocessor message object 52 or to the target message object 51. If the filter 
object chain scan direction is backward, the message is to be routed to a 
postprocessor message object 53. 

After step 712, the message transaction unit 44 determines whether the 
current filter object 56 as given by the second data field in the send MCB references 
10 another filter object 56 in accordance with the filter object chain scan direction in 
step 720. If another filter object 56 is referenced, the message transaction imit 44 
selects the next filter object 56 referenced along the filter object chain scan 
direction in step 732. Next, the message transaction imit 44 determines in step 732 
whether the selected filter object 56 has an associated preprocessor message object 
15 52 in the event that the filter object chain scan direction is forward, or whether the 
selected filter object 56 has an associated postprocessor message object 53 in the 
event that the filter object chain scan direction is backward. That is, the message 
transaction imit 44 determines whether the selected filter object 56 references a 
message object 58 in accordance vdth the filter object chain scan direction. If the 
20 selected filter object 56 does not reference a message object 58 in accordance with 
the filter object chain scan direction, the preferred method returns to step 720. If 
the selected filter object 56 references a message object 58 in accordance with the 
filter object chain scan direction, the message transaction unit 44 determines 
whether the message type specified in the send MCB matches a message type in 
25 the selected filter object's message type list. If not, the preferred mefl\od returns to 
step 720. If the message type specified in the send MCB matches a message type in 
the selected filter object's message type list, the message transaction imit 44 
identifies the message object referenced in the selected filter object 56 and in 
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accordance with the filter object chain scan direction as the current message object 
in step 736. After step 736, the message transaction unit 44 identifies the selected 
filter object 56 as the current filter object in step 738. Following step 738, the 
message transaction unit 44 updates the current results in the delivery MCB 80 
5 according to the current results specified in the continue message request in step 
739. Next, the message transaction unit 44 performs forward message operations 
in step 740, after which the preferred method ends. 

If the message transaction unit 44 determines in step 720 that the current 
filter object 56 does not reference another filter object 56 in accordance with the 

10 filter object chain scan direction, the message transaction unit 44 examines the 
filter object chain scan direction to determine if the most recent operations 
performed upon the message referenced by the send MCB had been associated 
with preprocessor message object 52 in step 722. If so, the message transaction unit 
44 identifies the target message object 51 as the current message object 58 in step 

15 726, after which the message traiisaction imit 44 identifies the last filter object 56 in 
the target message object's filter object chain 57 as the current filter object 56 in step 
728. Following step 728, the preferred method proceeds to step 740, 

If the message transaction imit 44 determines in step 722 that the filter 
object chain scan direction is backward, indicating that the most recent operations 

20 performed upon the message referenced by the send MCB had been associated 
with a postprocessor message object 53, the message transaction imit 44 next 
determines in step 750 whether the filter object stack in the send MCB is empty. If 
the filter object stack is not empty, the message transaction imit 44 selects the top 
entry in the filter object stack in step 752, and then identifies tiie corresponding 

25 filter object 56 as the current filter object in step 754. Next, the message transaction 
unit 44 deletes die top entry in the filter object stack in step 756. After step 756, the 
preferred method proceeds to step 732. 
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If the message transaction unit 44 determines in step 750 that the filter 
object stack is empty, the message transaction unit 44 next performs reply 
operations in step 750, after which the preferred method ends. 

Referring now to Figures 17A, 173, and 17C, a flowchart of a preferred 
5 method for performing forward message operations (step 140 of Figure lOB, step 
516 of Figure 14, and step 740 of Figure 16B) is shown. The preferred method 
begins in step 800 with the message transaction imit 44 decoding the message ID 
specified in the forward message request. Next, the message transaction imit 44 
determines in step 802 whether the message ID specified in the forward message 

10 request is valid. If the message ID is not valid, the message transaction imit 44 
returns an invalid ID error in step 804, after which the preferred method ends. If 
the message ID is valid, the message transaction tmit 44 synchronizes with 
message object locking operations in step 806. Next, the message transaction unit 
44 locates the send MCB corresponding to the message ID in step 808. The message 

15 transaction imit 44 then determines whether the send MCB is referenced in the 
current port object's pending reply message list in step 810. If so, the message 
transaction imit 44 removes the reference to the send MCB from the current port 
object's pending reply message list in step 811. After step 811, or after step 810, the 
message transaction unit 44 determines in step 812 whether the send MCB is a 

20 synchronous send MCB 60. If the send MCB is not a sjmchronous send MCB 60, 
the message transaction unit 44 determines in step 814 whether the forward 
message request indicates a port object 54 different from the current port object 54. 
If so, the message transaction unit 44 allocates a new asynchronous send MCB 62 
on the new port object 54 in step 816. The message transaction unit 44 then copies 

25 the data fields from the old asynchronous send MCB 62 into the new 
asynchronous send MCB 62 in step 818. 

After step 818, after step 814, or after step 812, the message transaction imit 
44 determines whether the forward message request indicates a new target 
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message object 51 in step 822. If so, the message transaction imit 44 determines in 
step 824 if the new target message object ID is valid in step 824. If the new target 
message object ID is not valid, the message transaction xmit 44 returns an invalid 
ID error in step 826, after which the preferred method ends. If the new target 
5 message object ID is valid, the message transaction unit 44 updates the filter object 
stack in either the synchronous send MCB 60 or the new asynchronous send MCB 
62 in step 828. In step 828, the message transaction unit 44 pushes in reverse order 
a reference to each filter object 56 in the original target message object's filter object 
chain 57 in the filter object stack of either the synchronous send MCB 60 or the 

10 new asynchronous send MCB 62. That is, references to filter objects 56 in the filter 
object chain 57 associated with the original target message object 51 are pushed 
onto the filter object stack beginning with the last filter object 56 in the filter object 
chain 57 to the first filter object 56 in the filter object chain 57. After step 828, the 
message transaction imit 44 identifies the new target message object 51 as the 

15 current message object in step 830. 

Following step 830, or after step 822, the message transaction imit 44 
determines whether a new asynchronous send MCB 62 had been allocated as a 
result of step 816. If so, the message transaction unit 44 deallocates the old 
asynchronous send MCB 62 on the old port object 54 in step 834. After step 834, or 

20 after step 832, the message transaction imit 44 updates the data fields in either the 
synchronous send MCB 60 or the new asynchronous send MCB 62 in step 836 by 
identifying the port object 54 associated with the current message object 58 as the 
current port object 54. The message transaction unit 44 next examines 
preprocessor message objects 52 in step 838, after which the message transaction 

25 unit 44 performs low-level send operations in step 840. After step 840, the 
preferred method ends. 

Referring now to Figure 18A and 18B, a flowchart of a preferred method for 
performing receive message operations (steps 144 and 158 of Figures lOB and IOC, 
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respectively) is shown. The preferred method begins in step 900 with the message 
transaction imit 44 decoding the port object ID specified in the receive message 
request. Next, the message transaction unit 44 determines whether the port object 
ID is valid in step 902. If the port object ID is not valid, the message transaction 
5 unit 44 returns an invalid ID error to the server task 34 that issued the receive 
message request in step 904, after which the preferred method ends. If the port 
object ID is valid, the message transaction imit 44 next determines whether a 
matching send MCB is present in the port object's pending send message list in 
step 906. If a matching send MCB is not present, the message transaction unit 44 
10 creates a receive MCB according to the type of receive message request issued, and 
inserts a reference to the receive MCB in the pending receive message request list 
in step 908. Following step 908, the message transaction imit 44 determines 
whether the receive message request is synchronous in step 910. If not, the 
message transaction tmit 44 returns the receive ID to the server task 34 that issued 
15 the asynchronous receive message request in step 912, after which preferred 
method ends. If the receive message request is synchronous, the message 
transaction unit blocks the server task 34 that issued the receive message request 
in step 914. Next, in step 916, the message transaction unit 44 determines whether 
the maximum time interval specified in the receive MCB has been exceeded. If so, 
20 the message transaction unit 44 returns a timeout status to the server task 34 in 
step 918, after which the preferred method ends. If the maximum time interval 
has not been exceeded, tiie message transaction imit next determines whether a 
matching send message request has been issued in step 920. If not, the preferred 
method returns to step 916. If a matching send message request has been issued, 
25 the message transaction imit 44 generates a unique message ID and creates a 
corresponding send MCB in step 922. 

Following step 922, or following step 906 if a matching send MCB is present, 
the message transaction unit 44 inserts a reference to the send MCB in the port 
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object's pending reply message list in step 930. The message transaction unit 44 
then creates a delivery MCB 80 at the address specified in the receive message 
request or in the receive MCB in step 932. After step 932, the message transaction 
imit 44 determines whether the receive message request is a synchronous receive 
5 message request in step 934. If the receive message request is synchronous, the 
message transaction tmit 44 determines whether the server task 34 that issued the 
receive message request is blocked in step 936. If so, the message transaction unit 
44 unblocks the server task 34 in step 938. If the message transaction imit 44 
determines in step 934 that the receive message request is an asynchronous 

10 receive message request rather than a synchronous receive message request, the 
message transaction imit 44 notifies the server task 34 that issued the 
asynchronous receive message request in step 940. Following step 940, step 938, or 
step 936 if step 938 is not performed, the message transaction unit 44 delivers the 
message specified in the send MCB to the message buffer specified in the receive 

15 message request in step 942. After step 942, the message transaction unit 44 

determines whether a receive MCB corresponding to the receive message request 
had been created in step 944. If so, the message transaction unit 44 deletes the 
receive MCB and its corresponding reference in the peniding receive message list 
in step 946. After step 946, or after step 944 if step 946 is not performed, the 

20 preferred method ends. 

Referring now to Figures 19A and 19B, a flowchart of a preferred reply 
method is shown. The preferred method begins in step 1000 with the message 
transaction unit 44 decoding the message ID. Next, the message transaction unit 
44 determines in step 1002 whether the message ID is valid. If the message ID is 

25 not valid, the message transaction imit 44 returns an invalid ID error in step 1004, 
after which the preferred meAod ends. If the message ID is valid, the message 
transaction unit 44 locates the corresponding send MCB in step 1006. The message 
transaction imit 44 then determines whether the most-recent operation 
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performed upon the message is associated with a preprocessor message object 52 in 
step 1008. In step 1008, the message transaction unit 44 determines whether the 
current message object ID is identical to the preprocessor message object ID stored 
within the current filter object 56. If the most-recent operation performed upon 
the message is associated with a preprocessor message object 52, the message 
transaction unit 44 identifies the postprocessor message object 53 associated with 
the current filter object 56 as the current message object 58 in step 1010. After step 
1010, the message transaction unit 44 updates the current results in the delivery 
MCB 80 according to the current results specified in the reply in step 1011. Next, 
the message transaction tmit 44 performs forward message operations in step 1012, 
after which the preferred method ends. 

When the message transaction unit 44 determines in step 1008 that the 
current message object ID is identical to the preprocessor message object ID stored 
within the current filter object 56, the message transaction unit 44 performs steps 
1010 through 1012 to carry out the skip-ahead operation described above. That is, 
if a server task 34 issues a reply while performing a preprocessing service 
associated with a preprocessor message object 52, the message is routed directly to 
the postprocessor message object 53 associated with the preprocessor message 
object 52 without examining additional filter objects 56 in view of additional 
preprocessing, and without delivering the message to the target message object 51. 
The performance of any additional preprocessing services and the performance of 
the service associated with the target message object 51 are therefore skipped via 
the skip-ahead operation. 

If in step 1008 the message transaction unit 44 determines that the most- 
recent operation performed upon the message is not associated with a 
preprocessor message object 52, the message transaction unit 44 determines 
whether the current filter object 56 references a previous filter object 56 in step 
1014. If so, the message traitsaction unit 44 performs continue message operations 
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in Step 1018, after which the preferred method ends. If the message transaction 
unit 44 determines in step 1014 that the current filter object 56 does not reference a 
previous filter object 56, the message transaction imit 44 determines whether the 
filter object stack in the send MCB is empty. If the filter object stack is not empty, 
5 the preferred method proceeds to step 1018. If the filter object stack is empty, the 
message transaction imit 44 next delivers the reply status to the client task 32 
indicated in the send MCB in step 1020. The message transaction uiut 44 then 
determines in step 1022 whether a reply buffer was indicated in the reply. If so, the 
message transaction imit 44 delivers a copy of the contents of the reply buffer to 

10 the client task 32 in step 1024. After step 1024, or after step 1022 if no reply buffer is 
indicated in the reply, the message transaction imit 44 determines in step 1026 
whether the current message object 58 is to be imlocked upon completion of the 
message transaction. If so, the message transaction unit 44 issues a corresponding 
unlock request to the locking unit 46 in step 1028. After step 1026 or after step 

15 1028, the message transaction imit 44 deletes the message ID representing the 
message transaction in step 1030. Finally, the message transaction imit 44 deletes 
the send MCB in step 1032, after which the preferred method ends. 

Referring now to Figure 20, a flowchart of a preferred method for 
performing locking operations is shown. In the present invention, locking 

20 operations are performed in the same marmer as in U.S. Patent Application Serial 
No. 08/220,043. The preferred meftiod begins in step 1100 with the locking imit 46 
determining whether the message object ID specified in the lock request is valid. 
If the message object ID is not valid, the locking unit 46 returns an invalid ID error 
to the issuer of the lock request in step 1102, after which the preferred method 

25 ends. If the message object ID is valid, the locking unit 46 next determines in step 
1104 whether the mrasage object 58 is already locked by inspecting the list of locked 
message objects within the port object 54 with which the message object 52 is 
associated. In the preferred embodiment of the present invention, each element 

-49- 



wo 95/31780 



PCr/US9»0S457 



in the list of locked message objects is a lock structure that specifies a message 
object ID and a semaphore. If the message object 58 is not locked, the locking unit 
46 ignores new send message requests issued by client tasks 32 in step 1105, and 
then waits for a reply to be issued for each send MCB referenced in the associated 
5 port object's pending reply message list that specifies the message object 58 in step 
1106. Preferably, the locking unit 46 performs step 1106 by first counting the 
number of send message control blocks referenced in the pending reply message 
list that specify flie message object 58, after which the locking unit 46 waits for each 
of the references counted to be removed from the pending reply message list. 
10 After step 1106, the locking unit 46 locks the message object 58 by inserting a new 
lock structure containing the corresponding message object ID into the list of 
locked message objects. Next, the locking imit 46 returns control to the issuer of 
the lock request in step 1118, after which tiie preferred method ends. 

If the locking unit 46 determines in step 1104 that the message object 58 is 
15 already locked, the locking unit 46 next adds a reference to the lock request issuer 
to the corresponding lock structure semaphore in the list of locked message objects 
in step 1110. Preferably, the semaphore provides a FIFO-ordered lock wait list that 
indicates the client task ID or the server task ID of each task that is waiting to lock 
the message object 58. After step 1110, the locking unit 46 determines in step 1112 
20 whether the issuer of the currently-considered lock request is next to receive 

ownership of the message object's lock. In the preferred method, the locking unit 
46 performs step 1112 by determining whether tite ID of the issuer of tiie currently- 
considered lock request is at the front of the lock wait list. If the issuer of the 
currently-considered lock request is not next to receive ownership of the message 
25 object's lock. Hie preferred mediod remains at step 1112. 

Once tiie issuer of the currently-considered lock request is next to receive 
ownership of the message object's lock, the locking unit 46 determines whether an 
unlocking request has been issued in step 1114. If no unlocking request has been 
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issued, the preferred method remains at step 1114. After an unlocking request has 
been issued, the locking imit 46 responds to the unlock request by performing 
unlocking operations in step 1116. Following step 1116, the preferred method 
returns control to the issuer of the currently-considered lock request in step 1118, 
after which the preferred method ends. 

Referring now to Figure 21, a flowchart of a preferred method for 
performing imlocking operations is shown. In the present invention, imlocking 
operations are performed in the same manner as in U.S. Patent Application Serial 
No. 08/220,043. The preferred method begins in step 1200 with the locking unit 46 
determining whether the message object ID of the message object 52 indicated in 
the unlock request is valid. If the message object ID is not valid, the locking unit 
46 returns an invalid ID error to the issuer of the imlocking request in step 1202, 
after which the preferred method ends. If the message object ID is found to be 
valid in step 1200, the locking tmit 46 next determines whether the message object 
52 is currently locked in step 1204. Preferably, the locking unit 46 determines 
whether the message object 52 is currently locked by inspecting the associated port 
object's list of locked message objects. If the message object 52 is not currently 
locked, the locking xmit 46 returns a lock state error to the issuer of the unlocking 
request in step 1206, after which the preferred method ends. 

If the message object 52 is currently locked, the locking unit 46 next 
determines whether another task is waiting to assume ownership of the message 
object's lock in step 1208. The locking unit 46 preferably performs step 1208 by 
inspecting the semaphore associated with the message object 52. If no other task is 
waiting to assimie ownership, the locking unit 46 removes the corresponding lock 
structure from tiie corresponding port object's list of locked message objects in step 
1210, thereby unlocking the message object 52. After step 1210, the locking unit 46 
returns control to the issuer of the imlock request in. step 1214, after which the 
preferred method ends. If anther task is waiting to assume ownership of the 
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message object's lock in step 1208, the locking unit 46 removes the reference to the 
client task 32 or server task 34 at the front of the semaphore's lock wait list in step 
1212. Following step 1212, the preferred method proceeds to step 1214. 

While the present invention has been described with reference to a 
5 preferred embodiments, those skilled in the art will recognize that various 
modifications may be provided. Variations upon and modifications to the 
preferred embodiment are provided for by the present invention, which is limited 
only by the following claims. 
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APPENDIX A 



Nu-Kemel Operating System Im plementation of Message Object Filtering 
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Filter Content of NuKemel ERS 

(Material for Appendix-A) 



Filtering Object Messages 

A message filter is a pair of objects used to screen another object's messages. An object 
with filters is called a target . The set of installed filters on a target is called the filter chain.. 

Installed filters are designated by DD. The ID may be used to later remove the filter, or 
retrieve its installation information. 

Once installed, filters are completely transparent to both clients and servers. However, 
servers have complete control over which of its objects may become a target. 

If the target is deleted, all installed filters are automatically removed. If the target is locked, 
the lock applies to the entire filter chain. A target object's filter chain may be examined 
using an iterator service. 

There is no limit to the number of filters or the number of objects which can be filtered. 
Filter objects can share a single port; however, a filter can only screen a smgle object's 
messages. 

Message Filters 



The 'A' Filter 



SEND 




Pre-Processors Post-Processors 



Two kinds of message objects may be used in a filter. The first kind of object screens 
messages before they arrive at the target and is called a pre-processor. The second kind of 
object screens messages as they leave the target and is called a post-processor, A filter may 
be composed of just a pre-processor, or just a post-processor. 

A single message is passed through each filter and target object. The message is given first 
to the pre-processors, then the target, and finally the post-processors. 
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The SendMessage, SendMessageAsync, and ForwardMessage services invoke an object's 
pre-processors. The ReplyToMessage and CancelAsyncMessage services invoke its post- 
processors. The ContinueMessage service may be used by any object to pass the message 
to the next object in the chain. 

The ForwardMessage service stacks the remaining post-processors in the current filter 
chain before routing the message to a new target. Once die new target and its filters have 
completing processing, the stack of remaining post-processors is activated. 

A pre-processor object may issue a ReplyToMessage to jump over the target and begin 
post-processing, starting with the its twin . Any per-message state generated by a pre- 
processor object can be cleaned up by its twin.* 

The format of an object's message contents must be published if content modification filters 
are to be accommodated Message content version numbers are recommended so that 
filters may track format evolution. 



Filter Names 

All filters are named. Filters attached to the same target must have a unique name. Filters 
installed on separate targets may share names. 

A filter name consists of a service and signature type. The service type identifies the 
functionality provided by the filter. The signature type identifies the provider of the 
service. 



Filter Name 



Service Type 



Signature Type 



For example, an Apple supplied encryption filter might be named: 'ENCR'.'APPL'. The 
registration and allocation of signature types is to be managed by Apple Computer Inc. 



Filter Ordering 

Some filters require a guaranteed order of invocation widi respect to other filters. Ordering 
requirements are specified as a set of two rules. The first rule names a filter before and the 
second rule names a filter after the desired location in the filter chain. The combination of a 
before and after rule determines the placement within the filter chain. 

Filter Ordering 



Before Rule 



After Rule 



Service Type 



Signature Type 



Service Type 



Signature Type 
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WHAT IS CL AIMED IS: 

1. A message filtering method for an object oriented message filtering 
system having a processing unit and a memory wherein an object oriented 
message filtering unit, a client task and a server task reside, the message filtering 
method comprising the steps of: 

creating a port object; 

creating a target message object, for acting as a destination for a message 
specified by a send message request issued by the client task; and 

creating a filter object, for selectively indicating whether one from the 
group of a message preprocessing service or a message postprocessing service is 
required during a message transaction initiated by the send message request. 

2. The method of claim 1, further comprising the steps of: 
determining whether a message preprocessing service is required during 

the message transaction; and 

transferring the message to the server task in the event that a message 
preprocessing service is required. 

3. The message of claim 1, further comprising the steps of: 
determining whether a message postprocessing service is required during 

the message transaction; and 

transferring tiie message to the server task in the event that a message 
postprocessing service is required. 

4. The method of claim 1, furtiier comprising the steps of: 
storing a reference to the port object in the target message object; and 
storing a reference to the target message object in the filter object. 
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5. The method of claim 1, further comprising the steps of: 
creating a preprocessor message object; and 

storing a reference to the preprocessor message object in the filter object. 

5 6. The method of claim 1, further comprising the steps of: 

creating a postprocessor message object; and 

storing a reference to the postprocessor message object in the filter object. 

7. The method of claim 1, further comprising the steps of: 

10 generating a imique message identification signal to correspond to the 

message transaction initiated by the send message request; and 

creating a send message control block corresponding to the message 
identification signal generated. 

8. The method of claim 7, further comprising the steps of: 
determining whetfier a preprocessor message object is associated with the 

filter object; and 

storing a reference to the preprocessor message object in the send 
message control block in the event that the filter object has an associated 
preprocessor message object. 

9. The method of claim 8, further comprising the steps of: 
determining whether a receive message request from the server task 

matches the smd message control block; and 
25 if the receive message request matches the send message control block, 

issuing a signal to the server task to initiate a message preprocessing service 
corresponding to the preprocessor message object. 
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10. The method of claim 9, further comprising the step of determiiung 
whether a next filter object is associated with the target message object. 

11. The method of claim 10, wherein in the event that a next filter 
5 object is associated with the target message object, performing the steps of: 

determining whether a preprocessor message object is associated with 
the next filter object; and 

storing a reference to the preprocessor message object associated with the 
next filter object in the send message control block in the event that the next 
10 filter object has an associated preprocessor message object. 

12. The method of claim 9, further comprising the step of storing a 
reference to a postprocessor message object associated with the filter object in 
the send message control block. 

15 

13. The method of claim 9, further comprising the step of storing a 
reference to the target message object in the send message control block. 

14. The method of claim 13, further comprising the step of storing a 
20 reference to a next target message object in the send message control block. 

15. The method of claim 14, further comprising the step of storing a 
reference to the filter object associated with the original target message object in 
the send message control block. 

25 

16. The method of claim 7, further comprising the steps of: 
determining whether a postprocessor message object is associated with the 

filter object; and 
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Storing a reference to the postprocessor message object in the send message 
control block in the event that the filter object has an associated postprocessor 
message object. 

17, The method of claim 16, further comprising the step of determining 
whether a previous fUter object is associated with the target message object. 

18- The method of claim 17, wherein in the event that a previous filter 
object is associated with the target message object, performing the steps of: 

determining whether a postprocessor message object is associated with 
the previous filter object; and 

storing a reference to the postprocessor message object associated with the 
previous filter object in the send message control block in the event that the 
previous filter object has an associated postprocessor message object. 

19. The method of claim 17, further comprising the step of issuing a final 
reply to the client task in the event that a previous fUter object is not associated 
with the target message object. 

20. A means for object oriented message filtering comprising: 
means for creating a port object; 

means for creating a target message object associated with the port object; 

and 

means for creating a fater object associated with the target message object. 

21. The means for object oriented message filtering of claim 20, further 
comprising a means for creating a preprocessor message object. 
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22. The means for object oriented message filtering of claim 20, further 
comprising a means for creating a postprocessor message object. 

23. The means for object oriented message filtering of claim 20, further 
5 comprising: 

means for generating a unique message identification signal to correspond 
to a message transaction initiated by a send message request from the client task; 
and 

means for creating a send message control block corresponding to the 
10 message identification signal generated. 

24. The means for object oriented message filtering of claim 23, further 
comprising a means for storing a reference to one from the group of a 
preprocessor message object, a postprocessor message object, or a target message 

15 object in the send message control block. 

25. The means for object oriented message filtering of claim 23, further 
comprising a means for determining whether a receive message request issued 
by a server task matches the send message control block. 

20 

26. A system for object-oriented message filtering, for routing a 
message from a client task to one or more server tasks, the object-oriented 
message filtering system comprising: 

a memory having an input and an output for storing data and commands, 
25 the memory including an object management unit for creating a port object, a 
target message object, a filter object and a preprocessor message object, an object 
database for storing the port object, the target message object, the filter object and 
the preprocessor message object, and a message transaction tmit for creating a send 
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message control block in response to a send message request, for selectively storing 
a reference to the preprocessor message object in the send message control block, 
and for selectively storing a reference to the target message object in the send 
message control block; and 
5 a processing imit having an input and an output, for processing data and 

command under control of the memory, the input of the processing imit coupled 
to the output of ttie memory, and the output of the processing unit coupled to the 
input of the memory. 

10 27. A system for object-oriented, message filtering, for routing a 

message from a client task to one or more server tasks, the object-oriented 
message filtering system comprising: 

a memory having an input and an output for storing data and commands, 
the memory including an object maiuigement uiut for creating a port object, a 

15 target message object, a filter object and a postprocessor message object, an object 
database for storing the port object, the target message object, the filter object and 
the postprocessor message object, and a message transaction unit for creating a 
send message control block in response to a send message request, for selectively 
storing a reference to the target message object in the send message control block, 

20 and for selectively storing a reference to the postprocessor message object in the 
send message control block; and 

a processing unit having an input and an ou^ut, for processing data and 
command imder control of tiie memory, the input of the processing unit coupled 
to the output of the memory, and the output of the processing unit coupled to the 

25 input of the memory. 
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